Processing network address identifiers

ABSTRACT

The invention provides a method, data processing system and software for generating address identifiers for use in a communications network. The method comprises the step of processing a first address identifier constructed in accordance with a first communications protocol; and the step of constructing a second address identifier, from said first identifier, in accordance with a second communications protocol. The first communications protocol may be protocol Simple Mail Transfer Protocol (SMTP) and the second communications Session Initiation Protocol (SIP). The invention enables messages to be sent to a SIP URL derived from an SMTP email URL. In the event that the SIP URL is invalid, or unregistered the SIP message is diverted from a SIP defined destination URL address identifier to a corresponding SMTP defined destination URL address identifier for the same user or end system. In this way users may send SIP messages to SMTP address identifiers using the SMTP network protocol and infrastructure ( 416 ) and SMTP messages to SIP address identifiers using the SIP network protocol and infrastructure ( 408, 410, 412 ).

This application is the US national phase of international applicationPCT/GB01/01331 filed Mar. 26, 2001 which designated the U.S.

This invention relates to a method of operating a communicationsnetwork.

The Session Initiation Protocol (SIP) is an application-layer controlprotocol for creating, modifying and terminating sessions having one ormore participants. These sessions include Internet multimediaconferences, Internet telephone calls and multimedia distribution.Members in a session can communicate via multicast or via a mesh ofunicast relations, or a combination of these. SIP supports sessiondescriptions that allow participants to agree on a set of compatiblemedia types. It also supports user mobility by proxying and redirectingrequests to the user's current location. SIP is not tied to anyparticular conference control protocol. There is widespread interest inthe protocol, especially for telephony-related applications. SIP wasproposed by the Internet Engineering Task Force (IETF) group and is nowa proposed standard published as RFC 2543.

The entities used in SIP are user agents, proxy servers, redirectservers and location servers. A SIP user agent is an end-system thatallows a user to participate in a session. A SIP user agent containsboth a user agent client and a user agent server. A user agent client isused to initiate a session and a user agent server is used to respond torequest from a user agent client. A user is addressed using anemail-like address identifier “user@host”, where “user” is a user nameor phone number and “host” is a domain name or numerical InternetProtocol (IP) address. SIP defines a number of request types, inparticular INVITE, ACK, BYE, OPTIONS, CANCEL, and REGISTER. Responses toSIP messages indicate success or failure, distinguished by status codes,1xx (100 to 199) for progress updates, 2xx for success, 3xx forredirection, and higher numbers for failure. Each new SIP transactionhas a unique call identifier (call ID), which identifies the session. Ifthe session needs to be modified, e.g. for adding another media, thesame call identifier is used as in the initial request, in order toindicate that this is a modification of an existing session.

The SIP user agent has two basic functions: listening for incoming SIPmessages, and sending SIP messages upon user actions or incomingmessages. The SIP user agent typically also starts appropriateapplications according to the session that has been established. A SIPproxy server can relay SIP messages—it is possible to use a domain nameto find a SIP proxy server, for example using the Domain Name System(DNS), rather than knowing the IP address or name of the host. A SIPproxy can thereby also be used to hide the location of the user. Aredirect server returns the location of the host rather than relayingthe SIP message. Both redirect and proxy servers accept registrationsfrom users, in which the current location of the user is given. Theuser's location can be stored at a dedicated location server.

SIP is typically implemented by transmitting Internet Protocol (IP)packets. SIP is independent of the packet layer and only requires anunreliable datagram service, as it provides its own reliabilitymechanism. While SIP typically is used over UDP or TCP, it could be usedover frame relay, ATM AAL5 or X.25.

SIP is a text based protocol and is based to a certain extent (in termsof syntax) on the HTTP protocol. A typical message consists of a singlerequest line, a number of header lines and a message body.

The request line indicates the type of the messages, the messagedestination and the SIP version it complies with. The following is atypical example:

INVITE sip:Richard@bt.com SIP/2.0

A header line contains the name of the header type, followed by asemicolon and the contents as these are defined for the specific header.Consequently, each header type is used for a specific purpose (either toindicate some parameters or to issue a request). The following aretypical examples:

From: sip:Richard@bt.com

To: sip:Steve@bt.com

Subject: Official meeting

The message body may be of any content, although it usually has contentsformatted in accordance with the Session Description Protocol (SDP).

SIP URL address identifiers such as sip:Richard@bt.com are required forthe exchange of SIP messages in a similar way that e-mail URL addressidentifiers are required for the exchange of electronic mail.

By using an e-mail type address it is possible to deliver a SIP messageto a SIP server that knows the location of the user or user agent serverthe message is intended for. The IP address of the SIP server havingauthority for the callee's address can be readily determined by DNS. Theabove referenced proposed standard, RFC 2543, encourages implementers ofSIP services to name SIP servers by appending the string ‘sip.’ to theirdomain name. It is further suggested that an implementation might derivean address for use in SIP communications from the intended recipient'se-mail address. The proposed method of derivation is to add the prefix‘sip.’ to the host part of the intended recipient's e-mail address(e-mail addresses normally being of the form ‘user@host’).

According to an aspect of the present invention there is provided amethod of operating a network to provide communications in accordancewith a first communications protocol, said method comprising:

receiving a base address identifier convertible by a first directoryserver associated with said network to an address for use incommunications made in accordance with a second communications protocol;

derive, from said base address identifier, an amended address identifierconvertible by a second directory server to an address for use incommunications made in accordance with said first communicationsprotocol;

wherein at least part of said address identifiers is formed inaccordance with a hierarchical addressing scheme, said part comprising asequence of address identifier components, the position of a componentin said sequence indicating the level of said component in saidhierarchical addressing scheme;

said method being characterised in that said derivation involvesintroducing amended address components so that a plurality of baseaddress identifiers convertible by said first directory server areconverted to one or more amended address identifiers convertible by saidsecond directory server.

In this way, it is possible to derive unique address identifiers for newcommunications services to be provided over a newly implementedcommunications protocol from respective address identifiers provided forservices associated with a fully implemented communications protocol.The above method provides for a new address space to be created for usewith DNS or other address resolution systems for the provision ofcommunication services associated with a newly available communicationsprotocol. The invention also provides for translation between addressspaces. For instance, if a message is sent but not delivered to a useror location identified by an address identifier generated in accordancewith the above method, the address identifier can be resolved back toits respective original address identifier and the message sent to thelocation associated with that original address by means of a serviceavailable over the first communications protocol. In this respect,address resolution is readily achievable since the respective first andsecond address identifiers are directly derivable from one another. Thisavoids the usual requirement of providing and maintaining of a costlyaddress database for mapping respective first and second addressidentifiers. Another advantage of the above method is that the addressspace is readily scalable. For instance, by using the domain namehierarchy associated with the first communications protocol a new domainname hierarchy can be created and integrated, if appropriate, with DNS.A further advantage of the above method is that users can readilyaddress messages etc, for transmission over one communications protocolusing an address identifier associated with another communicationprotocol. The ability to make use of the address space associated with awidely implemented communications protocol is very important when, say,new services are to be introduced using a new protocol. For example, auser may address a message to another user using a new addressidentifier derived from a known identifier regardless of whether theuser is aware of the recipient's address identifier for the newlyintroduced protocol or whether the recipient has indeed been allocated anew address identifier or is capable of receiving the message over thenew protocol. The user sending the message only requires knowledge ofthe recipient's address identifier associated with the widelyimplemented protocol.

In contrast to the RFC 2543 proposal of adding an address component atthe lowest level of the domain name hierarchy, the present inventionprovides address components at a higher level than the lowest levelcomponent in the known e-mail address. The entries in the directory canbe concentrated in the directory server associated with the level of thehierarchy that corresponds to the added address component. Where, as isnormally the case, there are a plurality of instances of addresscomponents below the added address component, this enables the directoryservice for the first communications service to be provided by a singledirectory server rather than a plurality of directory servers.

Preferably, at least one of said one or more address components ispositioned in said sequence such that in said amended addressidentifier, said one or more added address components are associatedwith higher positions in said hierarchy than the address componentsderived from said base address identifier.

This has the advantage that all directory enquiries can be handled by adirectory server under the control of a party introducing said firstcommunications service.

In some embodiments, the base address identifier components are removedand replaced by amended address identifier components. However, inpreferred embodiments, one or more base address components aremaintained in said amended address identifier. This allows addresshierarchies which have evolved in relation to the base addressidentifier to be re-used in the provision of the second communicationsprotocol.

If all the components of the base address identifier are maintained inthe amended address identifier, then this gives the advantage that anaddress (e.g. an e-mail address) which is known to be unique in relationto the second communications protocol is also known to be unique inrelation to the first communications protocol. In addition, the baseaddress identifier can be re-created from the amended addressidentifier, thus allowing the second directory server to revert to thesecond communications protocol if desired and forward a message intendedto be sent in accordance with the first communications protocol inaccordance with the second communications protocol instead. This allows,for example, the second directory server, on receiving a SIP message forwhich it is unable to provide an address, to instead send an e-mail tothe intended recipient indicated that it has been unable to provide aSIP connection through to the recipient.

According to another aspect of the present invention, there is provideda method of generating address identifiers for use in a communicationsnetwork; said method comprising the steps of:

processing a first address identifier constructed in accordance with afirst communications protocol; and,

constructing a second address identifier, from said first identifier, inaccordance with a second communications protocol.

Preferably, said first identifier is processed in accordance with apre-determined set of rules to provide said second identifier.

Conveniently, said first identifier comprises at least one addresscomponent and said second identifier comprises at least one addresscomponent of said first identifier. In this way address components canbe common to both first and second address identifiers.

In preferred embodiments, said second identifier includes each addresscomponent of said first identifier. This simplifies address translationand allows users to intuitively derive one address identifier from theother identifier. This enhances the integration of services providedover a newly introduced communications protocol with services providedover an existing communications protocol.

Preferably, said step of constructing said second identifier comprisesthe step of adding one or more address components to said firstidentifier. This enhances the above mentioned advantages.

Conveniently, said method comprises the steps of adding at least oneprefix address component and at least one suffix address component tosaid first identifier. This provides for the addition of at least twofurther distinguishing address components.

In preferred embodiments, said prefix address component isrepresentative of the second communications protocol and said suffixcomponent is representative of a network domain associated with saidsecond network communications protocol. This allows users to identifythe communications protocol that is associated with the newly generatedaddress identifier and the network domain authority for that addressidentifier.

Preferably, said second communications protocol is an application layercontrol protocol. This provides for the implementation of userapplications and new communications services over said communicationsprotocol.

Conveniently, the control protocol conforms to Session InitiationProtocol. Thus SIP messages can be addressed to an existing addressidentifier, for example and e-mail address identifier constructed inaccordance with Simple Mail Transfer Protocol (SMTP), and translated toa corresponding SIP address identifier for transmission to a SIP useragent server regardless of whether the SIP address identifier is knownto the user. Thus, the present invention enables messages to be readilydiverted from a SIP defined destination URL address identifier to acorresponding SMTP defined destination URL address identifier for thesame user or end system. In this way users may send SIP messages to SMTPaddress identifiers using the SMTP network protocol and infrastructureand SMTP messages to SIP address identifiers using the SIP networkprotocol and infrastructure.

In preferred embodiments, a software program is arranged to implementthe method according to the above-described aspect of the invention.

According to another aspect of the invention there is provided a systemfor generating address identifiers for use in a communications network;said system comprising:

a processor for processing a first address identifier constructed inaccordance with a first communications protocol; and,

an address identifier constructor for constructing a second addressidentifier, from said first identifier, in accordance with a secondcommunications protocol.

The invention will now be described with reference to the accompanyingdrawings in which:

FIG. 1 a is a schematic representation of a typical SIP messagesignalling sequence in a network comprising a SIP re-direct server;

FIG. 1 b is a schematic representation of a typical SIP messagesignalling sequence in a network comprising a SIP proxy server;

FIG. 2 is a block diagram of a SIP user agent;

FIG. 3 is a block diagram of a SIP user agent graphical user interface;

FIG. 4 is a schematic representation of a communications networkcomprising a plurality of SIP enabled network domains; and,

FIG. 5 is a flow diagram of a method implemented in the communicationsnetwork of FIG. 4;

With reference to the drawings, typical signalling sequences are shownin FIGS. 1 a and 1 b between two user agents 100 and 102 connected overa communications network using a SIP redirect server 106 (FIG. 1 a), anda SIP proxy server 108 (FIG. 1 b). In both arrangements a SIP locationserver 110 is connected to the respective SIP network server for addressresolution.

In FIG. 1 a, user agent 100 sends a SIP Invite message 112 to user agent102. The Invite message is received at and processed by the re-directserver 106 to determine the network location of user agent 102. There-direct server sends a location query 114 to the location server 110.The location server determines the current network location of useragent 102 and sends this information to the re-direct server in amessage 116 for transmission to the user agent 100 in a message 118.User agent 100 then sends an Invite message 120 to user agent 102,either directly or via other SIP re-direct or proxy servers, which thenresponds by sending an acceptance message 122 to the user agent 100.User agent 100 completes the session or call set up procedure by sendingan acknowledgement 124. Once the session has been set up information canbe exchanged between the respective user agents.

In FIG. 1 b, user agent 100 sends a SIP Invite message 126 to user agent102 as before but instead of being processed by a re-direct server themessage is processed by the network proxy server 108. The proxy serversends a location query 128 to the location server 110. The locationserver determines the current network location of the user agent 102 andsends this information back to the proxy server in a message 130. Theproxy server then relays the Invite message to the user agent 102 bymeans of a message 132 which is processed by the user agent 102. A callacceptance message 134 is then sent back to the proxy server whichrelays a corresponding message 136 to the user agent 100. The user agent100 then sends an acknowledgement message 138 to the proxy server whichsimilarly relays a corresponding message 140 to the user agent 102.

With reference now to FIG. 2, a typical SIP user agent 200 comprises afront end system in the form of a graphical user interface (GUI) 202, aSIP client program 204, a SIP server program 206, a media module 208, anetwork interface 210 a SIP address cache 212, a SIP URL addressgenerator 214 and a SIP message processor 216.

A typical SIP GUI is shown in FIG. 3. The GUI 202 comprises a pluralityof buttons 302 to 310 each of which represents a different SIP requestmethod. Button 302 represents the SIP “INVITE” request for inviting acallee to a SIP session, button 304 represents the “OPTIONS” request fordiscovering the capabilities of the receiving terminal, button 306represents the “BYE” request for terminating a call or a call request,button 308 represents the “CANCEL” request for terminating incompletecall requests and button 310 represents the “REGISTER” request methodfor registering the current location of the user with a respectivedomain location database 110. The respective request methods are invokedby a user clicking the respective button, by mouse controlled cursorclick or otherwise. The GUI further comprises a text box 314 labelled“To: SIP URL” for user input, by keyboard entry or address book entryselection for example, of the SIP address identifier of an intendedcallee, that is to say the SIP destination message header field “To”; atext box 316 labelled “To: e-mail URL” for user input of the e-mailaddress identifier of the intended callee; and, a text box 318 labelled“Title” for displaying title information to identify the session. Afurther text box 320 is provided for the input of other SIP message textincluding for example other SIP header types and text comprising the SIPmessage body. Text may be input into any one of the text boxes 314, 316,318, 320 using known text processing means, for example, keyboard entry,selection from pull down menus or cut and paste text processingapplications.

The SIP message constructor is configured to process data entered intoany one of the boxes 314, 316, 320, 320 and construct a SIP messageincluding the relevant request type for transmission to an appropriateSIP network server. For example, the message constructor copies the textentered in the text box 314 to the SIP message header type “To:” in theSIP message being constructed. Other header types are determined by themessage constructor such as “Content-type:” and “Content length:” forexample.

The user agent client program is configured to initiate a SIP session or“call” and the user agent server program is configured to respond to acall. In this regard the user agent client program implements the SIPrequest methods Invite, Options, Bye, Cancel and Register, and the useragent server implements the methods Invite, Bye, Cancel and Ack methods.Messages are passed from the user agent client to the network interface210 for transmission to the intended callee associated with thedestination SIP URL address. SIP messages are received at thedestination end by the network interface and are processing by the useragent server. The media module 208 provides the necessary API's forsending system calls to appropriate media applications for processingdifferent media types once a SIP session has been established.

When a user wishes to initiate a SIP session, the user interacts withthe GUI 202 to construct a SIP Invite message including a destinationSIP or e-mail address. Once all the necessary data has been input to theGUI, including the SIP header types and message body, the messageprocessor constructs an appropriate SIP message for transmission to thecallee. In the event that the callee's SIP URL address is unknown to theuser, the user inputs the callee's SMTP e-mail address in the text box316. The e-mail address is then sent to the SIP URL generator 214.

The SIP URL generator 214 comprises a software program for generating aSIP URL address identifier from a respective SMTP e-mail addressidentifier for a respective user.

The SIP URL generator is configured to process the e-mail addressidentifier, in accordance with a set of pre-determined rules, togenerate a corresponding SIP URL address identifier for the callee. Inone arrangement, the e-mail address is processed by the SIP URLgenerator which adds a prefix address component to the existing e-mailaddress components “user@host” etc. The prefix address componentidentifies the communications protocol that the new URL is to be usedwith. In this embodiment “sip” is added as a prefix. A suffix addresscomponent is also added to identify a SIP domain name authority thenewly generated SIP URL address identifier is to be identified with. Inone example the SIP URL generator is configured to process the SMTPe-mail address “alan.oneill@bt.com” to derive the SIP URL addressidentifier “sip:alan.oneill@bt.com.sipit.com”, that is to say, to addthe protocol prefix “sip” and the domain suffix “sipit.com” to theexisting SMTP readable e-mail address “alan.oneill@bt.com”. Thus, theSIP URL generator is configured to generate SIP URL address identifiersby processing a respective address identifier constructed in accordancewith the Internet e-mail communications protocol SMTP. In anotherexample the SIP URL generator is configured to process the same SMTPe-mail address identifier to derive the SIP URL address identifier“sip:alan.oneill@bt.com.uk.sipit.com”, that is to say a geographicalidentifier “uk” is additionally added to the SMTP e-mail addressidentifier. The additional geographic identifier may assist scalabilityof the name space and hence network routing efficiency of the resultingSIP message, for example.

Referring now to FIG. 4, a plurality of network domains 400, 402 and 404are each connected to the Internet 406 by means of a respective SIPnetwork server 408, 410 and 412. In the network of FIG. 4 the SIPnetwork servers are configured for use both as SIP proxy and SIPre-direct servers. The SIP network servers provide access to and fromthe respective domains. Each network domain comprises a plurality of SIPuser agents 200(a–g). SIP user agents 200 a, 200 b and 200 c areconnected to the network server 408 in the domain 400, SIP user agents200 d, and 200 e are connected to the network server 410 in the domain402, and SIP user agents 200 f and 200 g are connected to the networkserver 412 in the domain 404. Each SIP network server is connected to arespective location server 110 for SIP address resolution and anassociated SIP to SMTP e-mail gateway 414. Each SMTP e-mail gateway isconnected to a respective SMTP Mail Transfer Agent (MTA) 416 forrelaying SMTP e-mail messages to respective destination SMTP MTA's overtransport layer TCP connections.

Each SIP to SMTP e-mail gateway 414 comprises an SMTP e-mail addressgenerator 418 and a message processor 420 which comprises an SMTP useragent. The e-mail address generator comprises software for generating anSMTP address identifier from a SIP URL address identifier. In thisregard the e-mail address generator is configured in a similar butreverse manner to the address generator 214. The e-mail addressgenerator is configured to process the SIP URL destination addressidentifier of an out going SIP message to derive a corresponding SMTPe-mail address identifier. The e-mail address generator processes theSIP URL address in accordance with the same pre-determined set of rulesas the SIP address generator 214, but processes these rules in reverseorder with respect to the address generator 214. For instance, in oneembodiment a SIP message arriving at the SIP to SMTP e-mail gateway 414is parsed to determine the destination SIP URL. The SIP URL is thenpassed to the SIP to e-mail address generator 418. The remaining part ofthe SIP message is re-formatted by the message processor 420 into SMTPformat suitable for transmission as an SMTP e-mail message.

In one embodiment the address generator 418 is programmed in accordancewith the above set of rules, that is to say to remove the protocolidentifier prefix “sip” from the SIP URL address and to remove the sipdomain suffix component “sipit.com”. The address generator sends there-formatted SMTP address identifier to the message processor where thenewly derived SMTP address is added to the re-formatted message as thedestination SMTP address for that message. The message processor addsthe newly generated SMTP address to the SMTP “To:” header field of arespective SMTP message. For example, the address generator 418 isprogrammed to derive the SMTP e-mail address identifieralan.oneill@bt.com from SIP URL “sip:alan.oneill@bt.com.sipit.com”.

The message processor 420 constructs an appropriate SMTP message fortransmission to the newly generated SMTP address according to thecontent of the respective SIP control message. For example, the SIPmessage payload, for example the SDP message component of the SIPmessage , is added as text to the respective SMTP message body fortransmission to the respective destination SMTP address. In the exampledescribed with reference to FIG. 3, the SDP text shown in box 320 isprocessed and added as text to the SMPT message payload by the messageprocessor 420.

With reference now to the flow diagram of FIG. 5, a user initiates a SIPsession in step 500 by interaction with the GUI 202 of a SIP user agent200. A data entry for each of the required data types is input by theuser including a destination SIP address in box 314 or, in the absenceof a known SIP URL for the intended recipient, an SMTP e-mail addressthat is known to be allocated to the recipient in box 316. Data relatingto the SIP message is processed into SIP format by the SIP messageprocessor 216 and is then submitted to the user agent client 204 by theuser selecting the Invite button 302 by mouse click or other data inputcommand. The user agent client determines in step 502 whether a SIP URLaddress has been provided or an SMTP e-mail address. If a SIP URL hasbeen provided processing proceeds to step 508. However, if an SMTPe-mail address identifier has been provided the user agent client sendsthe e-mail address to the address generator 214 for processing to arespective SIP URL address identifier in step 504. A respective SIP URLis generated in accordance with the above described method. In step 506the newly derived SIP URL address is added to the SIP destination headertype “To:” following the INVITE request type of the SIP message.

The SIP message is transmitted to the appropriate local SIP networkserver 408, 410 or 412 in step 508 to be relayed or re-directed to anetwork server associated with the destination SIP URL address. Thenetwork server that receives the SIP message queries its associatedlocation database 110 in step 510, using DNS or other address resolutionmeans, to determine the network server the SIP message should betransmitted to. In step 512 a network server having authority for thedomain for the destination SIP URL determines whether the destinationSIP URL address is a valid network address, that is to say, whether theSIP URL address has been allocated by the domain authority to a SIPuser. The SIP URL destination address is a valid network address if itcan be resolved by a location database using DNS or other resolutionmeans to a respective numerical IP address, for example. In this respectaddress resolution may involve querying other location databasesassociated with other network SIP servers or SIP domains in a similarway that DNS resolves numerical IP addresses. In step 514, if thedestination SIP URL address is valid, that is to say it has beenallocated to a respective user and can be resolved, the location serverreturns the IP address of the next SIP server that is configured torelay or re-direct the message or if appropriate the IP address of theend system currently associated with the destination SIP URL. The SIPmessage is sent to the next SIP network server or destination end systemin step 516. If the SIP URL is invalid, that is to say it has not beenallocated by the appropriate domain authority for use in the network, anappropriate SIP network server transmits the SIP message to anassociated SIP to SMTP e-mail gateway in step 516. The destination SIPURL may be invalid for instance because it was automatically generatedfrom a known e-mail address identifier in step 504 and no correspondingSIP address exists. Under these circumstances the message processor 420re-formats the SIP message to an SMTP message for communication over theInternet 406 in accordance with SMTP in step 518. In step 520 thedestination SIP URL address is processed by the address generator 418 instep 520 to derive the SMTP e-mail address encapsulated within the SIPURL address. Additional information and data is added to there-formatted SMTP e-mail message in step 522 including, for example thetext:

-   -   “You were called by SIP user <sender's SIP URL and associated        data> at <time, date> with message <SIP message body content        (SDP)> but you were not found in the SIP registration system.        You can register at <http hyperlink> where you can download a        SIP client.”    -   or,    -   “You were called by SIP user <sender's SIP URL and associated        data> at <time, date> with message <SIP message body content        (SDP)> but you were not found in the SIP registration system.        You can register using the attached http form <http registration        form with mailto: URI address>. A SIP client <SIP client        executable code> is attached.”

The SMTP message is sent to an associated mail transfer agent 416 instep 524 for transmission to the e-mail address derived in step 520using the SMTP network protocol. In step 526 the sender is informed bythe SIP server that the destination SIP URL was not valid and that themessage was instead re-formatted according to SMTP and sent to the SMTPe-mail address derived in step 520.

It will be seen that the other embodiments of the present inventioncould be readily implemented by the skilled person, for instance insteadof the SIP message being diverted to a SIP to e-mail gateway in theevent that the destination SIP URL address is invalid, a SIP messagecould be readily diverted to a SIP to e-mail gateway if the user or theend system associated with the user was unavailable or unwilling toreceive SIP messages at the time of message transmission. In oneembodiment, the respective SIP server selects an appropriate messagefrom an associated message library (not shown) for inclusion with theoriginal SIP message in step 522. The message library includes arespective delivery failure message for each SIP message deliveryfailure mode, including for example, destination SIP user agentunavailable, user unavailable, network connection failure, userunwilling to join SIP session or user unwilling to join designatedsessions, user will be available at <time, date>, etc.

It will also be seen that in other embodiments the SIP to e-mail gateway414 could be readily implemented in other network devices such as arespective network SIP server or a SIP user agent.

1. A method of operating a network to provide communications inaccordance with a first communications protocol, said method comprising:receiving a base address identifier convertible by a first directoryserver associated with said network to an address for use incommunications made in accordance with a second communications protocol;derive, from said base address identifier, an amended address identifierconvertible by a second directory server to an address for use incommunications made in accordance with said first communicationsprotocol; wherein at least part of said address identifiers is formed inaccordance with a hierarchical addressing scheme, said part comprising asequence of address identifier components, the position of a componentin said sequence indicating the level of said component in saidhierarchical addressing scheme; said method being characterised in thatsaid derivation involves providing amended address components so that aplurality of base address identifiers convertible by said firstdirectory server are converted to one or more amended addressidentifiers convertible by said second directory server.
 2. A methodaccording to claim 1 wherein at least one of said one or more addresscomponents is positioned in said sequence such that in said amendedaddress identifier, said one or more added address components areassociated with higher positions in said hierarchy than the addresscomponents derived from said base address identifier.
 3. A methodaccording to claim 1 in which one or more of said base addressidentifier components are maintained in said amended address identifier.4. A method according to claim 3 in which all of said base addressidentifier components are maintained in said amended address identifier.